【レポート】Amazon CultureとAWSの設計思想 ～マイクロサービスアーキテクチャとアジャイル開発～ – Developers.IO TOKYO 2019 #cmdevio
はじめに
こんにちは。AWS事業本部のKyoです。
2019年11月1日（金）に、クラスメソッド主催の技術カンファレンス「Developers.IO 2019 TOKYO」が開催されました。
本記事では、アマゾンウェブサービスジャパン株式会社 亀田様によるセッション「Amazon CultureとAWSの設計思想 ～マイクロサービスアーキテクチャとアジャイル開発～」をレポートします。
スピーカー
アマゾンウェブサービスジャパン株式会社
プロダクトマーケティング エバンジェリスト 亀田治伸 様
セッション概要
AWSはAmazonのカルチャーを色濃く引き継いだ組織形態をベースにしたアーキテクチャを採用しサービス開発が行われ、165を超えるサービスを提供しています。このセッションでは、AWSをご利用いただく開発者がより効果的にクラウドネイティブ開発を実現する方法や、アジャイル開発との関係性についてご紹介します。
レポート
Amazonのイノベーション文化
- 徹底した顧客志向
- 長期的指向
- 失敗を恐れず失敗から学ぶ
we start with the customer and work backwards
“私たちは、お客様体験を起点に逆算して考えます”
「地球上で最もお客様を大切にする企業であること」からも分かるようにとにかく顧客志向。顧客志向であることはサービス開発にいいことがある。
お客様の求めるもの
- お客様は常により良い「何か」を求めている
- それは言語化されていない、顕在化されていないこともある
- 自社の事業が順調なときは自社の視点に満足しがち → 外部の声が重要
- 「お客様を喜ばせる」がイノベーションを継続する意思に繋がる
- このマインドはAmazon, AWSの採用にも反映されている
- 今後10年、「何が変わるか」よりも 「何が変わらないか」 を考える方がより重要な知見を得られる可能性が高い
- お客様は早く、安く、より多くのもの、を欲している
- お客様は要望が普遍なら長期にわたる投資が可能
Working backwards
概要
- 顧客体験を明確・詳細化するためのプロセス
- 顧客 → アイデア → プレスリリース → ユーザマニュアル
- 企画のPRを書き上げることではない
- 社内の価値観を統一
- プレスリリースはワードで2ページ
Working backwards 5つの質問
- あなたのお客様は誰ですか？
- お客様の抱える課題や新しいチャンスは何ですか？
- お客様にとってのメリットは明確になってますか？
- どのようにしてお客様のニーズを知ったのですか？
- お客様のどのような顧客体験を得られますか？
進め方
- 議論、討議、質問で、とにかくアイデアを叩く
- 外資あるあるで、会議で発言しないのは許されない
- かなり攻撃的に感じるので、入社直後にびっくりする新入社員もいる
- AWSもこうして生まれた
- 2年, 60回以上の会議
- 特徴である「初期無料、従量課金」は後から出たアイデア
- マーケティング等にもこれは適応される
- （例）誰宛に、どんな広告を、どんなコンバージョンで、という文章を作る
Working backwardsには非常に時間がかかる。しかし、やっておかないと後工程で軸のブレが発生する。Working backwardsにかかる時間よりも、軸の修正に必要なエネルギーの方がはるかに大きい。
長期的思考
長期的に物事を考えていき、すぐには結果を求めない。
周囲から誤解されることを厭わない
- （例）初代kindle
- 容量が少ない(本数冊分)
- 電池持たない
- 本1冊分より重い
物流がいくら発展した世界においても、瞬間で本を届ける体験は不可能。そのソリューション。
失敗を恐れず失敗から学ぶ
イノベーションのために失敗を受け入れる
- Amazonがより大きな失敗をしていなければそれは長期的に危険な兆候
- 失敗したときに得た学びを社内に積み上げられればノーペナルティ
失敗から学ぶ
- 過去最大の失敗と言われるFire Phobne
- 高機能なアンドロイド
- 標準ではGoogle Marketplaceに繋がらない
- 日本では1年も販売していない
チームは解散。現在、ほとんどのメンバがAlexaの開発に従事している
人事評価
- 目標設定の全てのKPI達成は論理的にあり得ない
- 出来ているならば設定が低すぎたということ
- 目標はチャレンジングであり、創意工夫が必要
- 目標の達成は給料に影響しない
- 四半期に一回、何に挑戦し、何を学んだかワードにまとめる
- 創意工夫のプロセスとその結果が評価 → 出来たこと、出来なかったこと双方の考察
-
Two-way door, One-way door
- ほぼ全ての判断はBidirectional（引き返し可能）
- 引き返し不可能な判断は一般社員に訪れない（ただしメディア等のコミュニケーションだけは別）
- 四半期ごとにその結果、改善を文章でまとめて関係者で議論（backwardsと同じく割とアグレッシブ）
Narrative文化
- 原則パワーポイント禁止
- pptは講演者と聴講者のリズムに依存
- pptで発生する論理破綻は講演者のバックグラウンドに依存
- 本人がいなくても存続するものでなくてはならない
- 最終的には公式ドキュメントになるので、作者の名前を消す
マイクロサービスアーキテクチャとアジャイル開発
Amazonにおけるマイクロサービスアーキテクチャ
- Service-oriented architecture (SOA)
- 単一の目的
- httpsのAPIのみで連携
- お互いはブラックボックス
- デメリットとして、アプリケーションレポジトリの数が爆発する
Amazon.com はモノリシックアーキテクチャだった
- 密結合
- メンテナンス、ビルド、テストが困難
- 水平スケーリングは不可能で垂直スケーリングのみ
- どこを触るとどうなるかを判断できなくなる → 属人性の最大化
- 「デプロイしていいですか？」のメールのCcが無限に増殖し、最後はCEOにまで…。
Two-pizza teams
- ピザ2枚を囲める人数のチーム（アメリカのピザなので6-8人）
- 小さくそれぞれが自律的に動ける組織 → 主体性
- なにを作るかから実行までの全権限をもつ → 自律性
- スクラム開発と似ている
- デメリットとして、制御が難しい
Cloud Native アーキテクチャ
- リソースは伸縮可能
- セッションは腹持ちNG
- RESTful, stateless
- API経由で操作
- 冪等性
- CI/CD
- サーバレスとコンテナは必須ではない
- セットで語られることが多いが、必須という訳ではない
- 単純に相性がいい
- アジャイル開発との相性？
そもそもアジャイルとは？
- アジャイルソフトウェア開発宣言
- プロセスやツールよりも個人と対談
- ドキュメントよりも動くソフト
- 契約交渉よりも顧客との協調
- 計画に従うことよりも変化への対応
価値の最大化のみを目的とし、レガシー手法の変更を行う。
マイクロサービスとAPI
- 疎結合なAPI連携のみで有機的に結合
- 社内外に関わらずAPI利用者は全てお客様
- １つの目的のためのサービスなので、バージョンアップはほとんどAPIの挙動に影響する
- APIへの改修、新規のAPIのリリースはマイクロサービスの破綻に繋がる恐れがあるため、最大限の注意が必要
以上からマイクロサービスはウォーターフォール向き？
なぜアジャイルがマイクロサービスに向いている？ → 小さなウォーターフォールが並列で多数発生していると外部からはアジャイルのように見えるかもしれない
所感
過去のソリューション開発の中で、関係者間での価値感の統一の難しさを感じていた私にとって、Working backwardsは非常に共感できるものでした。
直接的な技術だけではなく、それが生まれた文化や土壌から学べることの大きさを感じるセッションでした。
なお、Working backwordsについてはワークショップも行われているようなので、機会を見つけて参加してみたいと思います。
【レポート】『「あなたのお客様は誰ですか？」から始まるAmazonのイノベーションのメカニズム、その手法をハンズオン』を受けてきた #AWSSummit
以上、何かのお役に立てれば幸いです。
![[レポート] JJUG CCC 2024 Fallに行ってきました](https://devio2024-media.developers.io/image/upload/v1730277254/user-gen-eyecatch/awivhjatkofztrkayhdv.png)
